Authenticated scannable code system

ABSTRACT

A method of electronically facilitating a commercial transaction can include displaying a first scannable code on a display of a user device, placing the user device adjacent to a scannable code reader device, scanning the first scannable code of the user device with the scannable code reader device. Further, the method can include displaying a second scannable code on the scannable code reader device, scanning the second scannable code with a camera on the user device, and displaying a digital payment scannable code to complete the commercial transaction.

BACKGROUND Technical Field

The present application relates to a system and method of authenticatingcommercial transactions, as well as authenticating electronic ticketsfor admission to an event.

Description of Related Art

Conventional commercial transaction and ticket authentication systemsare limited in that they are configured with limited one-waycommunication between an image and scannable code reader. Conventionalsystems and methods lack the ability to authenticate the originality orvalidity of a scannable code, such as a quick response (QR) code.

Hence, there is a need for improved commercial transaction and ticketauthentication systems.

DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the systems and methods ofthe present application are set forth in the appended claims. However,the systems and methods themselves, as well as a preferred mode of use,and further objectives and advantages thereof, will best be understoodby reference to the following detailed description when read inconjunction with the accompanying drawings, wherein:

FIG. 1 illustrates a flowchart diagram of a user account creationprocess within an Authenticated Scannable Code (ASC) system, accordingto an example embodiment;

FIG. 2 illustrates a flowchart of a user retail purchase process,according to an example embodiment;

FIG. 3 illustrates a flowchart diagram of a consumer-to-consumer payerinitiated payment process, according to an example embodiment;

FIG. 4 illustrates a diagram of a consumer-to-consumer payee initiatedpayment process, according to an example embodiment;

FIG. 5 illustrates a flowchart of a mobile consumer-to-consumer payerinitiated payment process, according to an example embodiment;

FIG. 6 illustrates a diagram illustrating a mobile consumer-to-consumerpayee initiated payment process, according to an example embodiment;

FIG. 7 illustrates a flowchart diagram of a process for a user sellingtickets, according to an example embodiment;

FIG. 8 illustrates a flowchart diagram illustrating a process for socialmedia integration, according to an example embodiment;

FIG. 9 illustrates a diagram of the data collection within the ASCSystem; according to an example embodiment;

FIG. 10 illustrates a front elevation view of a scannable code reader,according to an example embodiment;

FIG. 11 illustrates a right side elevation view of the scannable codereader, according to an example embodiment;

FIG. 12 illustrates a back side elevation view of the scannable codereader, according to an example embodiment;

FIG. 13 illustrates a detailed side sectional view of the scannable codereader of the embodiment of FIG. 11, schematically showing the power,electrical, and hardware components, according to an example embodiment;

FIG. 14 illustrates a detailed back side sectional view of the scannablecode reader of the embodiment of FIG. 12, schematically showing thepower, electrical, and hardware components, according to an exampleembodiment;

FIG. 15 illustrates a flowchart of a ticket search process in the ASCsystem, according to an example embodiment;

FIG. 16 illustrates a flowchart diagram of a user ticket purchasingprocess, according to an example embodiment;

FIG. 17 illustrates a diagram of a ticket holder engagement process,according to an example embodiment;

FIG. 18 illustrates a flowchart of a user ticket parameters process,according to an example embodiment;

FIG. 19 illustrates a diagram illustrating a ticket redemption process,according to an example embodiment;

FIG. 20 illustrates an example of a user device, in conjunction with theticket redemption process, according to an example embodiment; and

FIG. 21 illustrates a schematic view of a computer system, according toone example embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Illustrative embodiments of the system of the present application aredescribed below. In the interest of clarity, all features of an actualimplementation may not be described in this specification. It will ofcourse be appreciated that in the development of any such actualembodiment, numerous implementation-specific decisions must be made toachieve the developer's specific goals, such as compliance withsystem-related and business-related constraints, which will vary fromone implementation to another. Moreover, it will be appreciated thatsuch a development effort might be complex and time consuming but wouldnevertheless be a routine undertaking for those of ordinary skill in theart having the benefit of this disclosure.

In the specification, reference may be made to the spatial relationshipsbetween various components and to the spatial orientation of variousaspects of components as the devices are depicted in the attacheddrawings. However, as will be recognized by those skilled in the artafter a complete reading of the present application, the devices,members, apparatuses, etc. described herein may be positioned in anydesired orientation. Thus, the use of terms such as “above,” “below,”“upper,” “lower,” or other like terms to describe a spatial relationshipbetween various components or to describe the spatial orientation ofaspects of such components should be understood to describe a relativerelationship between the components or a spatial orientation of aspectsof such components, respectively, as the device described herein may beoriented in any desired direction.

Conventional commercial transaction and ticket authentication systemsare limited in that they are configured with limited one-waycommunication between an image and scannable code reader. Conventionalsystems and methods lack the ability to authenticate the originality orvalidity of a scannable code, such as a quick response (QR) code.

Traditional credit and debit cards, checks, and cash require individualsto be in physical possession of the item in order to conducttransactions and are susceptible to theft. Near Field Communication(NFC) technology can pose a threat of theft and fraudulent use bythieves that are in possession of NFC scannable code readers inproximity to an individual's bank card. Digital ticketing systems, suchas those commonly used by airlines, are unable to authenticate theoriginality or validity of a scannable code.

Moreover, conventional digital ticketing systems do not provide a meansof controlling secondary market transactions by the original vendor.Further, conventional commercial transaction and ticket authenticationsystems are limited in the methods of control of purchaser access totransaction authentication displays. In one conventional commercialtransaction and ticket authentication system, a purchaser may view atransaction authentication quick response (QR) code on a device andsubsequently take a screenshot picture of the code thereby facilitatingthe easy transfer of the transaction authentication through means oftransferring the screenshot picture from the device. Transfer oftransaction authentication codes by purchasers can facilitate fraudulentaction, reduce potential vendor profits, and lead to service denials ofvalid customers.

In the preferred embodiment, a scannable code is a QR code. In otherembodiments the scannable code may be a barcode, or any other scannableimage containing embedded information that may be read and interpretedby a camera. It should be appreciated that the exact scannable code isimplementation specific.

Referring to FIG. 1, the flowchart diagram depicts a process 100 forcreating a user account. In step 102, a user can first access theAuthenticated Scannable Code (ASC) system website using, for example,any electronic device, smartphone, or computer. Upon accessing thevenue's website or ASC website in step 104, the user may select tocreate a new account and proceed to a user account creation page. Theuser may enter appropriate profile and account information in step 106including, but not limited to: credit card and banking information,demographic information, and social network information, and a digitalcertificate may then be installed on a device. In some embodiments, adevice may be a smartphone or computer. The IP address for the user'sdevice may be documented in the ASC System database 1000 to authenticatethe user's device 2100 (see FIG. 20) upon future visits to the ASCwebsite. In step 108, the new user account is created within the ASCSystem database 1000 and a scannable code 2013 a (see FIG. 20) isassigned to the user in step 110. The scannable code 2013 a is a uniqueuser account scannable code. Once the user has created an account andhas been assigned the scannable code 2013 a, the user may then installand log in to the ASC application, via step 112, from the user's device2100. One important feature is that the user account is specificallytied to the user device, via digital certificates, IP address

Referring to FIG. 2, the flowchart diagram depicts a user retailpurchase transaction process 200. In step 202, once the user is in aretail establishment that utilizes the ASC system, the user may approachthe retailer cashier with items to purchase. In step 204, the cashierenters and totals the prices of items to be purchased by user. In step206, the user may then open the ASC application on the user's device2100 (see FIG. 20) and select the desired method of payment: creditcard, debit card, or checking account, to name a few examples. In step208, the ASC application displays the scannable code 2013 a (see FIG.20) and the camera 2102 (see FIG. 20) on the user's device is activated.In step 210, the user presents the user's device 2100, displaying thescannable code 2013 a to the scannable code reader 2000 (see FIGS.10-14). In step 212, the scannable code reader 2000 recognizes theuser's scannable code 2013 a and the ASC System database 1000 (seeFIG. 1) can transmit a corresponding scannable code 2013 b to thescannable code reader 2000. Scannable code 2013 b is an activationscannable code that is unique to the specific user's account. In step216, the scannable code reader 2000 displays the scannable code 2013 b.In step 218, the user scans the scannable code 2013 b displayed on thescannable code reader 2000 using the ASC application on the user'sdevice 2100. The user can scan the scannable code 2013 b by utilizingthe user's device camera 2102. In step 220, the ASC application readsand recognizes the activation scannable code 2013 b in order to unlockscannable code 2013 c. Scannable code 2013 c is the user's uniquedigital payment scannable code. In step 222, the ASC applicationdisplays the scannable code 2013 c. In step 224, the scannable codereader 2000 scans, reads, recognizes, and accepts the scannable code2013 c. In step 226, the cashier completes the transaction and the userreceives a physical or digital receipt, and the user retail purchasetransaction process 200 is completed.

Referring to FIG. 3, the flowchart diagram depicts the payer initiatedconsumer-to-consumer money transfer process 300. In step 302, the payercan launch the ASC application on the user's device 2100 and can electto make a payment in step 304. In step 306, the payer can enter thedollar amount to be paid. In step 308, the ASC system generates ascannable code 2013 a which can then transmitted to the payer's deviceand, in step 310, the scannable code 2013 a can be displayed on thepayer's device display. In step 312, the payee can launch the ASCapplication, and, in step 314, may elect to scan the payment and thepayee's device camera can be activated. In step 316, the payee scans thescannable code 2013 a on the payer's device display, and, in step 318,the ASC system transfers the funds from the payer to the payee. In step320, the payee's device may display a message confirming the transfer offunds. Lastly in step 322, the payer's device may also display a messageconfirming the transfer of funds.

Referring to FIG. 4, the flowchart diagram depicts the payee initiatedconsumer-to-consumer money transfer process 400. In step 402, the payeelaunches the ASC application, and the payee may elect to receive apayment in step 404. In step 406, the payee enters the dollar amount tobe received. In step 408, the ASC system generates a scannable code 2013a, which can then be transmitted to the payee's device and, in step 410,the scannable code 2013 a can be displayed on the payee's devicedisplay. In step 412, the payer may launch the ASC application, and, instep 414, may elect to scan the payment, and the payer's device cameracan be activated. In step 416, the payer scans the payee's devicedisplay, and, in step 418, the ASC system transfers funds from the payerto the payee. In step 420, the payee's device may display a messageconfirming the transfer of funds. Lastly in step 422, the payer's devicemay also display a message confirming the transfer of funds.

Referring to FIG. 5, the flowchart diagram depicts the payer initiatedconsumer-to-consumer mobile transfer process 500. The payer launches theASC application in step 502, and the payer can elect to make a paymentin step 504. The payer enters the dollar amount to be paid in step 506.The ASC system generates a scannable code 2013 a in step 508, which canthen be transmitted to the payer's device and the scannable code 2013 acan be displayed on the payer's device display in step 510. The payermay elect to send the scannable code 2013 a via text or email in step512. In step 514, the payer may select the payee from contacts, ordirectly input other payee specific data like a mobile number or emailaddress. In step 516, the payee may receive and select a link providedin a message, for example a text or email message, which may launch theASC application in step 516. The payment details may be displayed on thepayee's device and the payee may accept or reject the payment in step518. If the payee accepts the payment in step 520, the ASC System cantransfer funds from the payer's account to payee's account in step 522.Once the funds have been transferred, a message confirming thesuccessful transfer of funds may be sent to both parties, for example,being displayed on the payee's device in step 524, and the payer'sdevice in step 526.

Referring to FIG. 6, the flowchart diagram depicts the payee initiatedconsumer-to-consumer mobile transfer process 600. The payee launches theASC application in step 602, and the payer can elect to receive apayment in step 604. The payee enters the dollar amount to be paid instep 606. The ASC system generates a scannable code 2013 a in step 608,which can then be transmitted to the payee's device and the scannablecode 2013 a can be displayed on payee's device's display in step 610.The payee may then elect to send the scannable code 2013 a via text oremail in step 612. In step 614, the payee selects the payer fromcontacts, or directly inputs mobile number or email address of payer. Instep 616, the payer receives and clicks the link provided in a text oremail message. In step 618, the payment details can be displayed on thepayer's device display and the payer can elect to accept or reject thepayment. If the payee accepts the payment in step 620, the ASC systemcan transfers funds from the payer's account to payee's account in step622. Once the funds have been transferred, a message confirming thesuccessful transfer of funds can be displayed on the payee's devicedisplay in step 624, and the payer's device display in step 626.

The ASC system transaction processes facilitate financial transactionsthat: are more convenient than cash, have more potential benefits andopportunities for data gathering than credit cards, more secure thanboth cash and credit cards, and more smart devices in use today arecapable of running the ASC application than Near-Field Communication(NFC) based transactions. The ASC system and smart device applicationenable the exchange or transfer of funds between friends, family,strangers, and businesses and customers without disclosing the user'ssensitive personal credit card or account information. Additionally,these transactions may be conducted in a physical face-to-facesituation, or over long distances via a cellular or wireless network.Because of the unique methodology of the ASC system, even if someonewere to take a screenshot of a user's payment code, it would not satisfythe authentication process and the original user's payment and accountinformation is protected. Even in a situation where a user's smartdevice is stolen, without the original user's ASC system passcode, orfingerprint authentication, the user's payment and account informationis safe within the ASC system application; unlike other items such ascash or credit cards that can also be stolen.

Referring to FIG. 7, which illustrates the process 700 through whichusers may list previously purchased tickets for sale on the ASC system,venue, or event website. In step 702, the user can access their ASCaccount via computer or other device, and in step 704 the user mayselect the previously purchased tickets which they have since decided tosell. In step 706, the user can select to dispose of tickets by way ofan auction format, or the user may input a set price. Once the ASCsystem database 1000 (see FIG. 1) receives the user's input, the user'stickets may be published on the ASC website as available for purchase,as illustrated in step 708.

Referring to FIG. 8, a diagram depicts the process 800 through which oneuser may engage another user using the social media integrationcapabilities of the ASC system database 1000 (see FIG. 1). In step 802,the user's social media data is captured and stored in ASC systemdatabase 1000 upon the user completing the new user account process. Instep 804, Facebook, Twitter, and other social media networks may beintegrated with the user account. In step 806, upon user's purchase oftickets, a posting may be made to their social media page and, in step808, the user's friends and social network contacts may see the postingas well as a message that informs the user's friends whether there areseats still available next to the user. In step 810, other ASC systemusers who are friends with the ticket holder through social media mayclick on a posting to see available tickets, and purchase any amount oftickets as needed through ticket purchase process 1600 (see FIG. 16).

Referring to FIG. 9, a system integration diagram 900 illustrates how auser can progress and complete various processes. For example, user mayselect the user account creation process 100, ticket search process1500, ticket purchase process 1600, engage ticket holder process 1700,ticket redemption process 1900, sale of tickets by consumer process 700,or social media integration process 800. After the user selects one ofthe processes, the information and data can be captured in the ASCsystem database 1000 (see FIG. 1). In step 902, The ASC system database1000 may perform a data tracking process to track and gather, amongothers, user profile/demographic information and purchasing/sellinghabits and patterns. In step 906, the user's data captured in the ASCSystem database 1000 may then be analyzed and provided to clients,venues, event websites, and the like, in order to refine marketingstrategies.

Referring to FIGS. 10-14, one embodiment of a scannable code reader 2000is illustrated. In a preferred embodiment, the scannable code reader2000 is encased in a hard shell 2001. In one embodiment, the scannablecode reader 2000 may have front face dimensions of seven inches inheight by four inches in width. In a preferred embodiment, the scannablecode reader 2000 has a display screen 2002 configured for displaying thescannable code 2013 b (see FIG. 20). In some embodiments, the displayscreen 2002 is covered by a protective piece that is made out of atranslucent plate 2012. In other embodiments, the display screen 2002(see FIG. 13) may be oriented such that the face of the scannable codereader 2000 slopes back at an angle to facilitate specific needs of theembodiment.

Referring to FIG. 11, which illustrates a side view of one embodiment ofa scannable code reader 2000. FIG. 11 shows the slope of one possibleembodiment. The slope may vary in other embodiments in order tofacilitate specific needs of the embodiment. In one embodiment, thedimension of the hard shell 2001 may be five and one half inches inlength. This dimension may vary in other embodiments.

Referring to FIG. 12, which illustrates a rear view of one embodiment ofa scannable code reader 2000. In one embodiment, the hard shell 2001 hasan upper communication port 2003 and lower communication port 2004. Thetwo communication ports may aid in the transfer of data to and from thescannable code reader 2000 in order to facilitate a user's desiredapplications. In one embodiment, a power cable 2005 may be used toprovide the necessary power to the scannable code reader 2000.

Referring to FIG. 13, which illustrates a side view of the inside of anexample embodiment of a scannable code reader 2000. In this exampleembodiment, the hard shell includes a clear plate 2012. In someembodiments the clear plate 2012 may be tempered glass. The exampleembodiment has an upper communication port 2003 and lower communicationport 2004. The example embodiment includes a wireless network adapter2008 capable of connecting a device to an available wireless network.The communication ports 2003 and 2004 may aid in the transfer of data toand from the scannable code reader in order to facilitate a user'sdesired applications. The example embodiment uses a power cable 2005connected to a power supply to provide the necessary power to thescannable code reader 2000. A display screen 2006, capable of displayingscannable codes, facilitates the communication to a user device from thescannable code reader 2000. An upper camera 2007 a and a lower camera2007 b are capable of reading, scanning, or otherwise interpreting ascannable code displayed on the user's device. The software and codingneeded to operate the scannable code reader may be stored in the circuitboard 2011 of the example embodiment.

Referring to FIG. 14, which illustrates a back view of the inside of anexample embodiment of a scannable code reader 2000. In this exampleembodiment, the hard shell 2001 includes a clear plate 2012. In someembodiments the clear plate 2012 may be tempered glass. The exampleembodiment has an upper communication port 2003 and lower communicationport 2004. The example embodiment includes a wireless network adapter2008 capable of connecting a device to an available wireless network.The communication ports may aid in the transfer of data to and from thescannable code reader in order to facilitate a user's desiredapplications. The example embodiment uses a power cable 2005 connectedto a power supply to provide the necessary power to the scannable codereader. A display screen 2002, capable of displaying scannable codes,facilitates the communication to a user device from the scannable codereader. An upper camera 2007 a and lower camera 2007 b are capable ofreading, scanning, or otherwise interpreting a scannable code displayedon a device facilitates the communication from a user device to thescannable code reader 2000. The software and coding needed to operatethe scannable code reader may be stored in the circuit board 2011 of theexample embodiment.

Referring to FIG. 15, a new ticket search process 1500 is illustrated.In step 1502 the user may search the ASC website via computer, or theASC application via mobile device, for events by, for example, specificname, date, location, or category. In step 1504, the user may select thedesired event or ticket, which they intend to purchase. In step 1506,the user can see any tickets available for sale through venue or agent,as well as tickets for sale by other users. Step 1508 facilitates theintegration of the user's social network information with the ASC systemdatabase 1000 (see FIG. 1), and step 1510 displays an available map of avenue and available seats or tickets indicating where the user'sfriends, based on the social network connections and relationships, arelocated. In some embodiments, step 1512 may sort the available tickets,for example, by: price, location, quantity, proximity to friends, directpurchase from venue or ASC website or application, or purchase fromother user. In step 1514, once the user has identified the seats ortickets the user intends to purchase, the user may select the desiredtickets. In step 1516, the user determines if the tickets are listed forsale by the venue, ASC application, or other users, or if the user willinstead engage another user. If the tickets are listed for sale by thevenue, ASC application, or other users, the purchaser may proceed to theticket purchasing process 1600. However, if the user would like topropose an offer to another ticket holder, who happens to be sittingnext to or near the purchaser's friends, the user may proceed to theengage ticket holder process 1700 via the ASC system database 1000 (seeFIG. 1).

Referring to FIG. 16, the ticket purchasing process 1600 is illustrated.In step 1602, the user may enter their credit card and/or bankinginformation, if not previously done during the user account creationprocess 100. In step 1604, the user can make the selection as to whetherthe purchased tickets will be for themselves, for others as guests, orfor someone else as a gift. In step 1606, the user can elect that thetickets will be redeemed by the user or by another as a gift. If theuser elects, in step 1606, that the user will be redeeming the tickets,the user may elect, in step 1608, that the user will be attending theevent alone, or as part of a group. If the user elects that he or shewill be attending the event alone in step 1608, the user will review andconfirm, for example, the ticket selection, payment information, andtransfer information in step 1620. Thereafter, in step 1622, the ticketdata is downloaded from the ASC system database 1000 to the user'sdevice before the user begins the ticket parameters process 1800 (seeFIG. 18). If the user elects in step 1608 that he or she will attend theevent as a part of a group, the user may elect if the group will enterthe venue together or if the group will enter the venue separately andmeet at the seats in step 1610. If the user elects that the group willenter the event together in step 1610, the user will review and confirm,for example, the ticket selection, payment information, and transferinformation in step 1620. Thereafter, in step 1622, the ticket data isdownloaded from the ASC system database 1000 to the user's device beforethe user begins the ticket parameters process 1800. If the user electsthat the group will enter the event separately in step 1610 the user mayenter the username, e-mail, and/or mobile number for the other guests instep 1612, before the user will review and confirm, for example, theticket selection, payment information, and transfer information in step1620. Thereafter, in step 1622, the ticket data is downloaded from theASC system database 1000 to the user's device before the user begins theticket parameters process 1800. On the other hand, if the user elects instep 1606 that the tickets will be redeemed by others as a gift, theuser may enter, in step 1614, for example, the recipient's username,e-mail, or mobile number in order to transfer the tickets. In step 1616,the user may elect to transfer the tickets immediately, or at a laterspecified date. If the user elects in step 1616 to transfer the ticketsimmediately, the user will review and confirm, for example, the ticketselection, payment information, and transfer information in step 1620.Thereafter, in step 1622, the ticket data is downloaded from the ASCSystem database 1000 to the user's friend's device before the userbegins the ticket parameters process 1800. If the user elects in step1616 to transfer the tickets at a later specified date, the user mayenter the specific date when transfer should occur in step 1618, beforethe user will review and confirm, for example, the ticket selection,payment information, and transfer information in step 1620. Thereafter,in step 1622, the ticket data is downloaded from the ASC system database1000 to the user's friend's device before the user begins the ticketparameters process 1800.

Referring to FIG. 17, after the user has selected tickets or seats nearthe user's friends that have already been purchased by another ticketholder, the user may proceed to the engage ticket holder process 1700 topropose an offer to purchase their tickets. If the ticket holder has notpreviously provided a minimum price the user may enter paymentinformation and submit an offer to the ticket holder as a prospectivepurchaser in step 1708. On the other hand, if the ticket holder has seta minimum price and the ticket holder has made the minimum priceviewable to prospective purchasers, the user may enter paymentinformation and submit offer to ticket holder in step 1706. However, ifthe ticket holder has set a minimum price, and the ticket holder has notmade the minimum price viewable to prospective purchasers, the user maysubmit a blind bid, or offer, to the ticket holder for the tickets instep 1710. In step 1712, if the user's bid does not meet or exceed theticket holder's minimum amount, the user may increase their offer priceand re-submit their offer to the ticket holder in step 1714. If theuser's bid does meet or exceed the ticket holder's minimum amount instep 1712, the user's proposal will proceed to the ticket holder throughthe ASC system database 1000 (see FIG. 1). Once the user's proposedoffer has met or exceeded the ticket holder's minimum pricerequirements, the ASC system database 1000 will generate a notificationto the ticket holder in step 1716, notifying them of the proposed offerto purchase the tickets. After the ticket holder receives thenotification in step 1718, and reviewing the user's offer, the ticketholder may reject the offer in step 1720, and the user may begin a newticket search process 1500. Alternatively, the ticket holder may receivethe notification in step 1718 and accept the user's offer in step 1720at which point the ASC system database 1000 may transfer the ticket ortickets from the ticket holder's account to the user's account in step1724, and transfer the funds to the ticket holder's account.

Referring to FIG. 18, once the user has completed the ticket purchaseprocess 1600, the user may begin the ticket parameters process 1800. Instep 1802, the user may set parameters under which the user wouldconsider selling their tickets. In step 1804, if the user selects thatthey are not open to receiving offers, regardless of a prospectivepurchaser's proposed offer, no further action is necessary and thetransaction is terminated in step 1814. However, in step 1804, if theuser is open to receiving potential offers, they may then specifywhether there is a minimum price the user is willing to accept for theirtickets in step 1806. If the user selects that there is no minimum pricein step 1806, no further action is necessary and the transaction isterminated in step 1814. If the user selects that a minimum price isrequired in step 1806, the user should input the minimum amount requiredfor them to consider selling their tickets in step 1808. Once the userhas input the minimum amount in step 1808, the user may then selectwhether the minimum amount is made visible to prospective purchasers, orremains hidden in step 1810. If the user selects to have the minimumamount made public in step 1810, the minimum amount may be visible toother users who engage ticket holder through the ASC system in step1812.

Referring to FIG. 19, in step 1902, upon arriving at the venue, the usercan open the ASC device application on the user's device 2100 (see FIG.20) and select an appropriate ticket for the event. In step 1904, theASC application may simultaneously display the scannable code 2013 a(see FIG. 20), and activate the user device's camera. The scannable code2013 a is a unique user account scannable code. In step 1906, the usercan present the user device 2100, and display the scannable code 2013 a,to the scannable code reader 2000 (see FIGS. 10-14). Upon recognition ofthe scannable code 2013 a by the scannable code reader 2000 in step1908, the ASC system database 1000 (see FIG. 1) transmits the scannablecode 2013 b (see FIG. 20) to the scannable code reader 2000 in step1910. The scannable code 2013 b can be a unique activation scannablecode corresponding to the specific user's account. In step 1912, thescannable code reader 2000 can display the scannable code 2013 b on thedisplay screen 2002 of the scannable code reader 2000 (see FIGS. 10-14).In step 1914, the camera 2102 (see FIG. 20) on the user's device 2100,running the ASC application, scans and reads the scannable code 2013 bdisplayed on the scannable code reader 2000, upon which the ASCapplication recognizes the scannable code 2013 b presented by thescannable code reader 2000 to unlock the scannable code 2013 c in step1916. The scannable code 2013 c can be the user's digital ticketscannable code. In step 1918, after reading and accepting the scannablecode 2013 b, the ASC device application may display the scannable code2013 c to be read and confirmed by the scannable code reader 2000 instep 1920. In step 1920, upon confirmation of the scannable code 2013 cby the scannable code reader 2000, the user may be granted access to theevent venue and may receive a print out of the section and seat detailsin step 1922.

Referring to FIG. 20, in this example embodiment a user's device 2100may be oriented such that scannable code 2013 a faces the scannable codereader 2000. The scannable code 2013 a is a unique user accountscannable code that is assigned to the user when initially setting up anaccount. The scannable code 2013 a may be read by the camera 2007 a or2007 b of the scannable code reader 2000. In one embodiment, the usersimply lays the device 2100 face down on the clear plate 2012 of thescannable code reader 2000. The clear plate 2012 is configured toprotect the scannable code reader's display screen 2002 which maydisplay the scannable code 2013 b. Scannable code 2013 b is anactivation QR code that is created in response to reading the scannablecode 2013 a. The scannable code 2013 b can be a unique activationscannable code corresponding to specific ticket within the user'saccount specifically associated to the user device 2100. The scannablecode 2013 b can be read by the camera 2102 on the user's device 2100 andanalyzed by the application. Upon analyzing scannable code 2013 b, theuser's device 2100 can in turn unlock and display a scannable code 2013c. The scannable code 2013 c is the user's digital ticket scannablecode. The scannable code 2013 c is read by a camera (such as 2007 a or2007 b) of the scannable code reader 2000 and is affirmed (or possiblyrejected) allowing entry of the user to the venue.

The embodiments of the authenticated QR code system and method include ascannable code reader 2000 that is configured to both scan and read QRcodes, as well as the display screen 2002 to display QR codes, and theprocess, enabled through software, to authenticate QR codes. Asdescribed further above, the system can require the user/consumer tocreate a user account via a company website or Authenticated QR CodeSystem smartphone application, at which point, the user is assigned aunique customer account QR code. The user account can utilize digitalcertificates in order to associate user accounts with the specific userdevice (such as a smartphone, for example) or alternatively, canrecognize the unique IP address assigned to users electronic device.When a user purchases a ticket, or other digital item, through theirdevice, data of the digital ticket or transaction is immediatelydownloaded to the user's device, stored in the software program coding,unable to be viewed directly by the user. In order to redeem the digitalticket or transaction, the user utilizes the Authenticated QR CodeSystem smartphone application. Upon entering a venue for which the userhas purchased a digital ticket or transaction, the user can select theappropriate digital ticket or item in the Authenticated QR Code Systemsmartphone application and the user's unique account QR code isdisplayed on the smartphone to be read by the scannable code reader2000, and the camera 2102 on the device 2100 is activated. Once theAuthenticated QR Code Scanner reads the user's unique account QR code,the system identifies the specific account associated with the accountQR code and in turn displays an activation QR code, specific and uniqueto the user's account and ticket, to be read by the smartphoneapplication. The smartphone application detects the activation QR code,which unlocks the digital ticket QR code and is displayed on the screenof the smartphone to be read by the scannable code reader 2000. Thescannable code reader 2000 recognizes the ticket QR code as a valid andauthenticated digital ticket and the user is admitted to the event orvenue. Because the actual digital ticket is downloaded to the usersmartphone upon purchase, the Authenticated QR Code smartphoneapplication can function as necessary at the ticketing window, gate,venue, etc., regardless of whether a cellular or WiFi network isavailable. If a user attempted to take a screenshot, picture, or copy oftheir unique account QR code and send it to another individual to use,it would be a static image, incapable of interacting with the scannablecode reader 2000, and would be rejected. Providing added security, isthe fact that the user is unable to access, view, or transmit the actualticket QR code until the smartphone application receives the activationQR code provided by the scannable code reader 2000.

The ticket authentication system and method described herein providessignificant advantages over conventional ticketing systems and methods.For example, the ticket authentication systems and methods disclosedherein enable live entertainment venues, such as a sports stadiums,concerts, live theatre, etc. to regulate and monitor secondary markettransactions of tickets that occur subsequent to the original ticketpurchase from the venue or licensed agent. The ticket authenticationsystems and methods can insure that the spectator whom purchases theoriginal ticket from the venue or ticketing agency is the same one thatredeems the ticket upon entrance to the event, allowing the venue andspectator to capture the full value of the ticket. Further, because theactual digital ticket is downloaded to the customer smartphone uponpurchase, the application on the smartphone can function as necessary atthe ticketing gate regardless of whether a cellular or WiFi signal isavailable. If a customer was to attempt to take a screenshot or pictureof their unique account CR code and sent it to someone else for theiruse, then it would be a static image incapable of interacting with thescannable code reader 2000, and would be rejected. Security is providedby the prevention of the user from accessing, viewing, or transmittingthe actual ticket QR code until it receives the activation QR codeprovided by the scannable code reader 2000 at the point of entry intothe venue. Further benefits include: 1) enabling the monitoring andtracking of a ticket through the life of the ticket; 2) preventing theunauthorized transfer or sale of tickets without the knowledge orapproval of the original ticket seller; 3) enabling the easy transfer orsale of surplus tickets among customers, within the terms and conditionsspecified by the venue; and 4) allowing the transaction to take placewithout requiring the user to have cellular or WiFi signal on the user'sdevice.

Referring now also to FIG. 21, a computer system 2101 is schematicallyillustrated. Computer system 2101 can be configured for performing oneor more functions with regard to the operation of the systems andmethods further disclosed herein. Further, any processing and analysiscan be partly or fully performed by computer system 2101.

The system 2101 can include an input/output (I/O) interface 2103, ananalysis engine 2105, and a database 2107. Alternative embodiments cancombine or distribute the input/output (I/O) interface 2103, analysisengine 2105, and database 2107, as desired. Embodiments of the system2101 can include one or more computers that include one or moreprocessors and memories configured for performing tasks describedherein. This can include, for example, a computer having a centralprocessing unit (CPU) and non-volatile memory that stores softwareinstructions for instructing the CPU to perform at least some of thetasks described herein. This can also include, for example, two or morecomputers that are in communication via a computer network, where one ormore of the computers include a CPU and non-volatile memory, and one ormore of the computer's non-volatile memory stores software instructionsfor instructing any of the CPU(s) to perform any of the tasks describedherein. Thus, while the exemplary embodiment is described in terms of adiscrete machine, it should be appreciated that this description isnon-limiting, and that the present description applies equally tonumerous other arrangements involving one or more machines performingtasks distributed in any way among the one or more machines. It shouldalso be appreciated that such machines need not be dedicated toperforming tasks described herein, but instead can be multi-purposemachines, for example computer workstations, that are suitable for alsoperforming other tasks.

The I/O interface 2103 can provide a communication link between externalusers, systems, and data sources and components of the system 2101. TheI/O interface 2103 can be configured for allowing one or more users toinput information to the system 2101 via any known input device.Examples can include a keyboard, mouse, touch screen, and/or any otherdesired input device. The I/O interface 2103 can be configured forallowing one or more users to receive information output from the system2101 via any known output device. Examples can include a displaymonitor, a printer, phone display, and/or any other desired outputdevice. The I/O interface 2103 can be configured for allowing othersystems to communicate with the system 2101. For example, the I/Ointerface 2103 can allow one or more remote computer(s) to accessinformation, input information, and/or remotely instruct the system 2101to perform one or more of the tasks described herein. The I/O interface2103 can be configured for allowing communication with one or moreremote data sources. For example, the I/O interface 2103 can allow oneor more remote data source(s) to access information, input information,and/or remotely instruct the system 2101 to perform one or more of thetasks described herein.

The database 2107 provides persistent data storage for system 2101.While the term “database” is primarily used, a memory or other suitabledata storage arrangement may provide the functionality of the database2107. In alternative embodiments, the database 2107 can be integral toor separate from the system 2101 and can operate on one or morecomputers. The database 2107 preferably provides non-volatile datastorage for any information suitable to support the operation of systemsand methods described herein, including various types of data discussedfurther herein. The analysis engine 2105 can include variouscombinations of one or more processors, memories, and softwarecomponents.

The particular embodiments disclosed above are illustrative only, as thesystem may be modified and practiced in different but equivalent mannersapparent to those skilled in the art having the benefit of the teachingsherein. Modifications, additions, or omissions may be made to theapparatuses described herein without departing from the scope of theembodiment. The components of the system may be integrated or separated.Moreover, the operations of the system may be performed by more, fewer,or other components.

Furthermore, no limitations are intended to the details of constructionor design herein shown, other than as described in the claims below. Itis therefore evident that the particular embodiments disclosed above maybe altered or modified and all such variations are considered within thescope and spirit of the application. Accordingly, the protection soughtherein is as set forth in the claims below.

1. A method of electronically facilitating a commercial transaction, themethod comprising: displaying a first scannable code on a display of auser device; placing the user device adjacent to a scannable code readerdevice; scanning the first scannable code of the user device with thescannable code reader device; displaying a second scannable code on thescannable code reader device; scanning the second scannable code with acamera on the user device; displaying a digital payment scannable codeto complete the commercial transaction.
 2. The method according to claim1, wherein at least one of the first scannable code, the secondscannable code, and the digital payment scannable code is a quickresponse (QR) code.
 3. The method according to claim 1, furthercomprising: prior to displaying a first scannable code on a display of auser device, a retailer entering a purchase price and a user opening anapplication on the user device and selecting a method of payment.
 4. Themethod according to claim 1, further comprising: verifying the firstscannable code by a communication between the scannable code reader anda database; and wherein the database generates the second scannable codewhich is unique to a user account that is associated with the userdevice.
 5. The method according to claim 1, further comprising:analyzing the second scannable code by an application on the user deviceprior to displaying the digital payment scannable code on the display ofthe user device.
 6. The method according to claim 1, further comprising:activating an Authenticated Scannable Code (ASC) application on the userdevice prior to displaying the first scannable code on the display ofthe user device.
 7. The method according to claim 6, further comprising:activating the camera on the user device in response to the activationof the Authenticated Scannable Code (ASC) application on the userdevice.
 8. The method according to claim 1, wherein displaying thedigital payment scannable code on the display of the user device tocomplete the commercial transaction includes scanning digital paymentscannable code by the scannable code reader device and completing thetransaction by generating a receipt.
 9. A method of electronicallyfacilitating a consumer-to-consumer financial transaction, the methodcomprising: displaying a scannable code on a display of a first userdevice; transmitting the scannable code from the first user device to asecond user device; displaying a payment detail on a display of thesecond user device; and accepting or alternatively rejecting a paymentof the transaction.
 10. The method according to claim 9, wherein theconsumer-to-consumer transaction can be initiated by either a payor or apayee of the transaction.
 11. The method according to claim 9, whereinthe scannable code is a quick response (QR) code.
 12. The methodaccording to claim 9, further comprising: prior to displaying thescannable code on the display of a first user device, opening anapplication on the first user device and entering an amount of thepayment.
 13. The method according to claim 9, wherein the step oftransmitting the first scannable code is performed by at least one oftext or email, via a link.
 14. The method according to claim 9, whereinthe step of accepting the payment includes transferring funds from thefirst user to the second user and generating a confirmation message tobe sent to both the first and second users.
 15. The method according toclaim 14, further comprising displaying the confirmation message on boththe first user device and the second user device.
 16. The methodaccording to claim 9, further comprising: activating an AuthenticatedScannable Code (ASC) application on the first user device prior todisplaying the first scannable code on the display of the first userdevice.